REMARKS 

The Office Action of November 17, 2005 has been carefully 
considered . 

Regarding the objection to the drawings under 37 CFR 
1.83(a), the downstream interface transceiver in a service 
card appears as block 70 in Fig. 2, and the upstream interface 
transceiver as block 20. However, for greater clarity, the 
"interface transceiver" has been replaced by "service 
interface" in claim 29. The service interface is shown by 
reference numeral 84 in Fig. 4 and by reference numeral 116 in 
Fig. 5. As stated in paragraph [0036] of the published 
application, "Service interface 84 can be, for example, an 
optical or electrical transceiver..." Service cards are shown a 
reference numerals 82 in Fig. 4 and 110 in Fig. 5, as well as 
in Fig. 2. 

Claims 5, 17 and 30 have been amended in accordance with 
the Examiner's request, to remove the informalities. 

Claims 2-3, 10, 15-21, 23-25, 27, 29, 30 and 32 are 
rejected under 35 USC 112, first paragraph, as being 
indefinite . 

Applicants have amended these claims in accordance with 
the Examiner's suggestions so that the language used is 
consistent . 

The Office Action alleges that it is unclear why there 
are two steps of sorting the services data, one in claim 1 and 
another in claim 30, since the steps are very similar in these 
two claims. Claim 1 relates to transmission of services data 
through a metro network between service collection units and 
aggregator units. The services data is received in one or 
more aggregators, where the services are sorted for 
transmission to their final destinations. Claim 30 clarifies 
that the received services data is sorted according to service 



type, and all services of the same type after sorting are 
aggregated for further transmission together. Claim 30 has 
now been amended to delete the phrase "from a plurality of 
packets" which may be confusing. 

Regarding claim 32, the Office Action alleges that it is 
unclear whether "a service collection unit" in line 11 of 
claim 32 is the same as the "at least one service collection 
unit" in claim 1. The answer is that the unit belongs to the 
group defined in Claim 1, but is not necessarily the same 
unit. In Claim 1, the service collection unit or units serve 
to collect services data from a plurality of sources for 
transmission into the metro network. In Claim 32, the service 
collection unit receives services in packets from the metro 
network. The receiving unit may be the same as the 
transmitting unit, or may be a different such unit. In order 
to clarify this issue, Claim 32 has been amended to indicate 
that the packets are unloaded in "at least one of said at 
least one service collection unit." 

It is alleged that there is insufficient antecedent basis 
for the limitation "said aggregated services data" in claim 2, 
since only sorted services data are aggregated. Claim 30 
depends from claim 1 which claims collecting and segmenting 
services data to form packets which are sent to an aggregator 
for sorting. Claim 30 adds the limitation of aggregating again 
the sorted services data, this time according to type of 
service. Claim 2 adds further method steps describing in 
greater detail the process in the aggregator. Therefore, claim 
2 has been amended to depend from claim 1 instead of claim 30, 
thereby providing proper antecedent basis for this term. 
Similarly, claim 32 should more appropriately depend from 
claim 1, and has been amended accordingly. 
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Regarding the term "each service" in claim 21, the claim 
has been amended to recite "each services data," for which 
there is antecedent basis in claim 1. 

Withdrawal of this rejection is requested. 

Claim 1 has been rejected under 35 USC 103(a) over Mo et 

al. 

The present relates to a method for data transmission and 
data receipt over an optical network. The method includes a 
number of novel steps, including collecting, in at least one 
service collection unit, services data in their original 
protocols from a plurality of different types of services to 
be transmitted, processing the services data in their original 
protocols into packets, converting the packets into optical 
signals on an optical fiber for transmission into a metro 
network, and sorting the services data from a plurality of 
converted packets in at least one aggregator module. Each of 
the service collection units and each of the aggregator 
modules has an optical transceiver, coupled for optical 
communication between them. 

The Office Action states that Mo et al discloses 
collecting services data in their original protocols from a 
plurality of different types of services, citing col. 8, lines 
12-24. 

It is submitted that the term "segmenting" as in the 
present application means cutting, where the bit streams of 
data services are cut into segments of different sizes and 
packetized in novel packets which are routed through a 
network. In the Mo et al patent, "segmenting" means sorting, 
as can be understood more particularly from col. 8, lines 11- 
17. The traffic, i.e., ready made data packets, is segregated 
and processed based on a two level, high/low priority scheme. 
The traffic flows may be segmented (i.e., sorted) into any 
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number of suitable traffic types, based on selected traffic 
type identifiers. 

The Mo et al reference discloses a device and method for 
separating data of a single service into different traffic 
types, namely, high priority or low priority. There is no 
teaching or suggestion or possibility of using different 
services, but only a single service, IP (Ethernet) packets. Mo 
et al uses the terminology "segmenting," but as noted above, 
it designates an entirely different function. As stated in the 
Abstract of Mo et al, the "method and system for transporting 
traffic in a packet-switched network segments high priority 
pass-through traffic from low priority pass-through traffic" 
(emphasis added). In col. 2, lines 55-61, Mo et al describes 
another technical advantage of the invention, namely providing 
class of service support for Internet protocol (IP) traffic . 
Traffic is distinguished and routed based on its class of 
service parameters, which allows high-priority traffic to be 
processed with minimal delay, and low-priority traffic to be 
delayed or dropped. Again, in the Detailed Description in col. 
3, lines 54-61, Mo et al states, "the transport network 10 is 
an Internet protocol (IP) network for transporting IP and 
Multiple Protocol Label Switch (MPLS) packets," or "any other 
packet-switched network operable to route...data packets based 
on network protocol addresses." 

In fact, the invention uses services to build traffic. 
The claimed method puts together the services into traffic 
which can then be routed according to the method of Mo et al. 
In other words, the invention is a level below or before the 
level of treatment of Mo et al. 

The Office Action further alleges that Mo et al processes 
the services data in their original protocols into packets, 
pointing to col. 8, line 32. Mo et al receive ready-made 
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packets and do not process any services data into packets; 
they merely route existing packets according to a priority 
scheme. Col. 8, lines 32-35 describes a transmit buffer which 
is suitably sized to hold two or more packets, operable to 
hold direct pass-through packets while the multiplexer 
processes a current packet, namely multiplexing the packets 
onto an optical fiber. As stated above, there is no teaching 
or suggestion or need or possibility in Mo et al for 
processing services data so as to form packets, as is done 
according to the claimed invention. 

It is also alleged in the Office Action that Mo et al 
includes an aggregator module (traffic buffer 150, local 
buffer 152, and multiplexer 124) for sorting the services data 
from a plurality of converted packets. It is respectfully 
submitted that the traffic buffer 150, local buffer 152, and 
multiplexer 124 form a router or switch, rather than an 
aggregator module according to the invention. As explained at 
col. 4, lines 8-10, col. 6, lines 19-21, and col. 8, lines 18- 
67, the Mo et al network includes a plurality of Internet 
protocol transport (IPT) nodes, each IPT node including one or 
more receiver-transceiver pairs (RTP) and a processing system 
interconnected by an internal Ethernet connection. The RPT 
includes a demultiplexer coupled to a receiver, and a 
multiplexer coupled to a transmitter, with the traffic buffer 
and local buffer between the demultiplexer and multiplexer. 
The demultiplexer includes a lookup table 162 for identifying 
pass-through and local traffic; the pass-through traffic goes 
via the traffic buffer to the transmitter, while the local 
traffic receives low-priority and is sent to the transmitter 
if there is available bandwidth. This system is not 
constructed, nor does it operate as does the aggregator of the 
invention, which includes at least one aggregator module for 
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sorting services data, in original protocols, from a plurality 
of packets formed in at least one service collection unit by 
collecting and processing services data from a plurality of 
different types of services, only one of which is IP protocol 
service . 

The Office Action states that Mo et al fails to 
explicitly show an aggregator optical transceiver, stating 
that is would be obvious to combine a metro network and an 
aggregator optical transceiver with Mo et al for the benefit 
of a bigger transport network. 

While optical transceivers, per se, were known in the 
art, Mo et al fails to show "an aggregator optical 
transceiver" because such an aggregator did not exist before 
the claimed invention. A device carrying out the functions of 
the aggregator of the invention was not known to one skilled 
in the art before the filing date of the present application. 
There is no device shown in Mo et al or otherwise known to the 
Applicants which sorts services data from a plurality of 
converted packets prepared by a service collection unit as 
described in the invention, and transmits on optical signals 
to the device over a network. This is precisely the novelty of 
the present invention which Applicants are claiming. 
Withdrawal of this rejection is requested. 
Claim 1 has been provisionally rejected on grounds of 
obviousness-type double patenting over claim 1 of co-pending 
application serial no. 09/753,513. Thus far, neither present 
claim 1 nor claim 1 in the co-pending application has been 
found to be allowable over the art. Should claim 1 be found 
to be allowable in both applications, a terminal disclaimer 
will be filed to remove this rejection. 

The allowability of claims 5-9, 11, 12, 14, 22 and 31 has 
been noted. Claim 5 has been placed in independent form, with 
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claims 8-12 and 15-20 depending directly or ultimately from 
claims 5. Claims 5, 8-12 and 15-20 are deemed to be 
allowable . 

In view of the foregoing amendments and remarks, 
Applicants submit that the present application is now in 
condition for allowance. An early allowance of the 
application with amended claims is earnestly solicited. 




spectfully submitted, 



Ira J. Schultz 
Registration No. 28666 



